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PRE-VERIFICATION OF CHECKSUMS USED WITH 
CHECKSUM-BASED HEADER COMPRESSION 

CROSS-REFERENCES TO RELATED APPLICATIONS 

5 This Application for Patent claims the benefit of priority from, and hereby 

incorporates by reference the entire disclosure of, co-pending U.S. Provisional 
Application for Patent Serial No. 60/188296 filed March 10, 2000. 

BACKGROUND OF THE PRESENT INVENTION 

10 Field of the Invention 

The invention relates generally to packet communications and, more 
particularly, to header compression in packet communications. 
Description of the Related Art 

The tremendous success of the Internet has made it desirable to expand the 
15 Internet Protocol (IP) to a wide variety of applications including voice and speech 

communication. The objective is, of course, to use the Internet as a link for 
transporting voice and speech data. Speech data has been transported across the 
Internet using IP-based protocols such as the User Datagram Protocol (UDP) and the 
Real-time Transport Protocol (RTP) . In a typical application, a computer running 

2 0 telephony software converts speech into digital data which is then assembled into IP- 

based data packets that are suitable for transfer across the Internet. Additional 
information regarding the UDP and RTP protocols may be found in the following 
publications which are incorporated herein by reference: Jon Postel, User Datagram 
Protocol, DARPA RFC 786, August 1980; Henning Schulzrinne et al., RRT: A 
25 Transport Protocol for Realtime Applications, IETF RFC 1889, IETF Audio/video 

Transport Working Group, January 1996. 

A typical IP-based speech data packet 10 is shown in FIG. 1. The packet 10 is 
one of a plurality of related packets that form a stream of packets 10 representing 
speech data being transferred over a packet-switched communication network such as 

3 0 the Internet. The packet 10 is made of a header portion 12 and a payload portion 14. 

The header 12 may include static information 16 such as the source and destination 
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addresses of the packet 10, and dynamic information 18 such as the IP identification, 
RTP sequence number, and RTP time stamp. 

FIG. 2 illustrates a pertinent portion of an exemplary packet-switched 
communication network 20. A packet source 22 such as the Internet provides a stream 
5 of IP-based data packets 10 across a link 24 to an access technology 26 such as, for 

example, a base station. The access technology 26 compresses the data packets 10 
received from the packet source 20 and transmits the compressed packets across a link 
28 to a receiver 30 such as, for example, a mobile cellular station. The link 28 may be 
any radio interface between the access technology 26 and the receiver 30 such as, for 
10 example, a cellular link. The receiver 30 receives the compressed packets from the 

access technology 26 and decompresses the packets, including reconstruction of the 
packet headers. 

In ordinary speech data transported over IP-based protocols, however, the 
header 1 2 may represent up to 70% of the data packet 1 0, leaving little capacity for the 
15 payload 14. For cellular links, this inefficient use of bandwidth is much too expensive 

for IP-based transportation to become a viable alternative to circuit switched speech 
services. Therefore, some compression or reduction of the header 12 is generally 
required. 

The term header compression refers to the art of minimizing the necessary 
2 0 bandwidth for information carried in packet headers on a per hop basis over point-to- 

point links. The headers are compressed or otherwise reduced at the transmitting side 
and then reconstructed at the receiving side. As mentioned previously, headers 
generally comprise both static information and dynamic information, that is, 
information that may change from one packet to the next. Header compression is 

2 5 usually realized by sending only the static information initially. Dynamic information 

is then transferred by sending only the change, or delta, from the previous packet. 
Completely random information is usually sent without compression. 

Under such a compression scheme, it is important to keep the states, also 
known as "context," of the various header fields consistent between the compressor 

3 0 and decompressor because reconstruction of the current packet depends on the context 

of the previous packets. For example, consider a packet that was somehow lost or 
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damaged during transmission from the compressor to the decompressor. The 
decompressor will not have been updated with the context of that packet. 
Consequently, any changes, or deltas, in the header fields of the next packet will be 
offset by one packet, and the decompressor may not be able to correctly reconstruct the 
5 header for the new packet. 

There are generally three factors to consider in maintaining context 
consistency: (1) compression efficiency, (2) robustness, and (3) reliability. 
Compression efficiency relates to how much the headers are compressed and can 
generally be expressed by the average compressed header size. Robustness, on the 

10 other hand, relates to how well a compression scheme handles loss over a predefined 

link. For example, will a loss make the contexts inconsistent, possibly resulting in a 
large number of erroneously decompressed packet headers? Reliability relates to how 
trustworthy a scheme is in terms of catching incorrectly decompressed packets. Any 
header compression scheme, in order to be feasible, must take at least these factors 

15 into account. 

One presently available header compression protocol is the ROCCO protocol 
(RObust Checksum-based header Compression). ROCCO is a header compression 
protocol that uses checksums to verify the correctness of the reconstructed headers at 
the decompressor side. The particular checksum used is CRC (cyclical redundancy 

2 0 checking). In ROCCO, a CRC is calculated over the full original IP/UDP/RTP header 

by the compressor and then included in the compressed header. The compressed 
header (with the included CRC) is then sent to the decompressor where it is 
reconstructed. Once the header is reconstructed, a new CRC is calculated over the full 
reconstructed header. This new CRC is then compared with the included CRC to see 
25 if there is a match, which means the header reconstruction was performed correctly. 

CRC calculation is well-known to those of ordinary skill in the art and will not 
be discussed here. Suffice it to say, however, the size of the CRC impacts the 
compression efficiency and reliability of the header compression scheme. For 
ROCCO, a CRC length of 1 0 bits is commonly used. In general, a long CRC provides 

3 0 higher reliability, but lower compression efficiency. A short CRC, on the other hand, 

provides higher compression efficiency, but lower reliability. As such, longer CRCs 
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are generally favored in order to ensure strong reliability, often at the expense of 
compression efficiency. It is desirable, therefore, to be able to generate a CRC that 
provides high reliability without compromising compression efficiency. 

The present invention advantageously provides a CRC that has high reliability, 
5 yet does not unnecessarily compromise compression efficiency. In accordance with the 

invention, a CRC is pre-verified at the compressor before it is sent to the 
decompressor. The pre-verification ensures that the CRC is of sufficient length to 
provide robustness and reliability, but is not unnecessarily lengthy. 

SUMMARY OF THE INVENTION 

10 The present invention is directed to a method or apparatus for pre- verifying 

checksums to ensure the checksums are reliable for header decompression purposes. 
The checksums are preverified at the compressor side before being transmitted to the 
decompressor. Verification of the checksums includes testing against a number of 
packet loss scenarios to ensure reliable detection of errors. In addition, pre-verification 

15 helps increase and/or maintain compression efficiency by keeping the length of the 

checksums from becoming unnecessarily long. 

In one aspect, the invention is related to a method of verifying a checksum in 
a header compression protocol. The method comprises the steps of calculating a 
checksum, based on a packet header, compressing the packet header in accordance 

20 with the header compression protocol, and testing the checksum, for reliability prior 

to including the checksum in the compressed packet header. 

In another aspect, the invention is related to a system for verifying a checksum 
in a header compression protocol. The system comprises a checksum calculator for 
calculating a checksum based on a packet header, a compressor for compressing the 

25 packet header in accordance with the header compression protocol, and a reliability 

processor for testing a reliability of the checksum prior to including the checksum in 
the compressed packet header. 

A more complete appreciation of the present invention and the scope thereof 
can be obtained from the accompanying drawings which are briefly summarized 

3 0 below, the following detailed description of the presently-pref erred embodiments of 
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the invention, and the appended claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the method and apparatus of the present 
invention may be obtained by reference to the following Detailed Description when 
5 taken in conjunction with the accompanying Drawings wherein: 

FIGURE 1 illustrates a typical speech data packet.; 

FIGURE 2 illustrates a packet-switched communication environment; 

FIGURE 3 illustrates a general packet flow according to an embodiment of the 
present invention; 

1 0 FIGURE 4 illustrates a general flow of the checksum preverification process 

according to the embodiment of FIGURE 3; 

FIGURE 5 illustrates a compressor apparatus according to the embodiment of 
FIGURE 3; and 

FIGURE 6 illustrates a decompressor apparatus according to the embodiment 
15 of FIGURE 3. 

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED 
EXEMPLARY EMBODIMENTS 

The present invention will now be described more fully hereinafter with 
reference to the accompanying drawings, in which preferred embodiments of the 

20 invention are shown. This invention may, however, be embodied in many different 

forms and should not be construed as limited to the embodiments set forth herein; 
rather, these embodiments are provided so that this disclosure will be thorough and 
complete, and will fully convey the scope of the invention to those skilled in the art. 
As mentioned previously, ROCCO calculates a CRC over the full original 

2 5 IP/UDP/RTP header at the compressor and then includes that CRC in the transmitted 

compressed header. Once the compressed header is reconstructed at the decompressor, 
a new CRC is calculated over the full reconstructed header. This new CRC is then 
compared to the included CRC to see if there is a match, which means the 
reconstructed header is correct. If the verification fails (i.e., the CRCs do not match), 
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ROCCO provides for local repair of the reconstructed header by additional 
reconstruction attempts based on one or more assumptions about what may have 
happened during transmission of the packet. (Hence the term "robust" in the name of 
the protocol.) Examples of events that may have occurred during the transmission 
5 include reordering of the packets, damaged packets, and lost packets, all of which may 

result in a packet loss from the decompressor's perspective. 

The first additional reconstruction attempt assumes there was no packet loss. 
Subsequent reconstruction attempts assume a single preceding packet was lost, 
then two preceding packets lost, and so on. For each reconstruction attempt, the 
10 decompressor alternately assumes a zero, one, or two packet loss, and so on, and 

calculates a new CRC based on the most probable context assuming the packet (s) 
were lost. 

The present invention takes advantage of the repair feature in ROCCO by pre- 
verifying the CRC before including and sending it with the compressed header. Figure 

15 3 illustrates the general packet flow according to one embodiment of the present 

invention. At step 300, header compression is performed in accordance with the 
ROCCO protocol. A CRC is calculated over the full, original header at step 302. At 
step 304, the CRC is verified for reliability, a process which will be explained in more 
detail herein. If the CRC is reliable, step 306, the CRC is included with the packet and 

20 sent to the next destination, step 308. If the CRC is not reliable, than a different, 

reliable CRC is sent instead, or additional information such as extra header fields is 
sent with the packet at step 310. 

Once the compressed header including the CRC is sent to the receiver via the 
link 28, it is reconstructed at step 320. At step 322, the type of CRC is determined, 

2 5 e.g., the standard CRC, or a modified version for CRCs that were not considered to be 

reliable. 

At step 324, the reconstructed header is verified by calculating a new CRC for 
the reconstructed header and comparing it against the included CRC. If verification is 
confirmed, step 326, the decompressed packet including the reconstructed header is 

3 0 forwarded to the intended application. If verification is not confirmed, i.e., the newly 

calculated CRC does not match the included CRC, the packet is discarded at step 328. 
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As mentioned previously, reliability relates to the trustworthiness of a 
compression scheme. To this end, the CRC should be of a sufficient length to be able 
to catch most or all erroneous header reconstructions. The present invention considers 
two factors in calculating such a CRC: the order and assumptions made by the 
5 decompressor in its repair attempts, and the number of actual lost packets that can be 
tolerated, as specified at the receiver side. 

Consider the exemplary case where only three lost packets can be tolerated, 
i.e., the decompressor will assume up to three preceding packets were lost in its repair 
attempts before discarding the packet as damaged. Based on this scenario, the 
1 0 compressor of the present invention would calculate a CRC that meets the following 

"MUST FAIL" criteria: 

Errors Reconstruction attempts MUST FAIL if 

One packet lost CRCs calculated for 0 packet loss 
Two packets lost CRCs calculated for 0 packet loss 

15 CRCs calculated for 1 packet loss 

Three packets lost CRCs calculated for 0 packet loss 

CRCs calculated for 1 packet loss 
CRCs calculated for 2 packet loss 
The above criteria maybe better understood with reference to the flow diagram 

20 of FIG. 4 in further illustration of the reliability verification process (shown in step 

304) . At step 400, the calculated CRC is checked to see whether it can catch a 1 
packet error if it is assumed that no packet loss occurred. In other words, if a true 1 
packet error occurred during transmission and the decompressor began repair under 
the (wrong) assumption that there was no packet loss, generating a new CRC 

25 accordingly, would the calculated CRC catch {i.e., not match) the newly generated 

CRC? If no, the compressor must recalculate the CRC at step 412, possibly resulting 
in a longer CRC with each recalculation. The check is repeated for up to a 3 packet 
error with an assumption of 2 packets loss, steps 402-410. If the CRC passes the last 
check, step 410, the process stops at step 414 and no more checks are performed 

3 0 according to this exemplary embodiment. 

Once the calculated CRC passes all the checks, it is considered pre- verified for 



WO 01/67715 



PCT/SE01/00468 



-8- 

reliability purposes and the length of the CRC is fixed. Thus, the present invention 
ensures the length of CRC will not be any longer than it needs to be for reliability 
purposes, thereby helping to at least maintain a high level of compression efficiency. 
However, if after a certain predefined number of recalculations have transpired or a 
5 certain predefined CRC length has been reached, the CRC is then considered to be 

unreliable. In that case, the CRC may still be included in the packet (step 3 1 0 in FIG. 
3) if additional information about the CRC is included. 

FIG. 5 illustrates an embodiment of the present invention as implemented in 
the access technology 26. The access technology 26 includes a packet compressor 50 

1 0 for compressing a data packet such as the data packet 1 0 (shown in FIG. 1 ) , including 

the header therein. A CRC calculator 52 calculates a CRC based on the original, 
uncompressed header of the received packet. A reliability processor 54 then checks the 
calculated CRC for reliability in accordance with the flow diagram illustrated in FIG. 
4. If the CRC is sufficiently reliable, it is included with the compressed header, and the 

15 compressed packet is then sent to the receiver 30 via the transmitter 56. If not, 

additional information may be sent as explained previously. 

Referring to FIG. 6, the receiver 30 includes a packet decompressor 60 for 
decompressing the compressed packet and reconstructing the header therein. A CRC 
extractor 62 extracts the included CRC and determines whether it is a standard CRC 

20 or a modified one (such as in the case of an unreliable CRC). A verification processor 

64 calculates a new CRC based on the reconstructed header and then compares it to 
the included CRC. If there is a match, the header reconstruction process is considered 
to be correct, and the packet is sent to a codec 66 for further processing. If no match, 
then an error has occurred, and the verification processor 64 attempts to repair the 

2 5 error in accordance with the ROCCO protocol. 

The previous description is of a preferred embodiment for implementing the 
invention, and the scope of the invention should not necessarily be limited by this 
description. The scope of the present invention is instead defined by the following 
claims. 
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WHAT IS CLAIMED IS: 

1 . A method for verifying a checksum in a header compression protocol, 
the method comprising the steps of: 

calculating a checksum based on a packet header; 
5 compressing said packet header in accordance with said header compression 

protocol; and 

testing said checksum for reliability prior to including said checksum in said 
compressed packet header. 

2. The method according to claim 1, further comprising reconstructing said 
10 packet header and verifying said decompressed packet header using said checksum. 

3. The method according to claim 2, further comprising reconstructing said 
packet header again in response to an erroneous previous reconstruction. 

4. The method according to claim 1, further comprising modifying said 
checksum in response to said checksum failing said testing. 

15 5. The method according to claim 1, further comprising including additional 

header information in said compressed header packet in response to said checksum 
failing said testing. 

6. The method according to claim 1, wherein said checksum is a CRC 
checksum. 

20 7. The method according to claim 1, wherein said header compression 

protocol is a ROCCO header compression protocol. 

8. The method according to claim 1 , wherein said testing comprises testing said 
checksum against a predefined number of actual packet errors, assuming a predefined 
number of packets lost. 
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9. A system for verifying a checksum in a header 
compression protocol, the system comprising: 

a checksum calculator for calculating a checksum based on 
a packet header; 

5 a compressor for compressing said packet header in 

accordance with said header compression protocol; and 

a reliability processor for testing a reliability of said 
checksum prior to including said checksum in said compressed 
packet header. 



10 10. The system according to claim 9, further comprising a decompressor 

for reconstructing said compressed packet header. 

11. The system according to claim 10, further comprising a verification 
processor for verifying said decompressed packet header using said checksum. 

12. The system according to claim 10, wherein said verification processor 
15 repeats reconstruction of said packet header in response to an erroneous previous 

reconstruction. 



13. The system according to claim 9, wherein said reliability processor 
modifies said checksum, in response to said checksum failing said testing. 

14. The system according to claim 9, wherein said reliability processor includes 
2 0 additional header information in said header packer in response to said checksum. 

failing said testing. 

15. The system according to claim 9, wherein said checksum is a CRC 
checksum. 



16. The system according to claim 9, wherein said header compression 
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protocol is a ROCCO header compression protocol 

17. The system according to claim 9, wherein said reliability processor tests 
said checksum, against a predefined number of actual packet errors, assuming a 
predefined number of packets lost. 
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